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METHOD FOR CHARGING FOR A SERVICE IN A COMMUNICATION 

NETWORK 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] This application is the US National Stage of International Application No. 
PCT/EP2004/053227, filed December 2, 2004 and claims the benefit thereof. The 
International Application claims the benefits of European application No. 03029454.0 EP 
filed December 19, 2003, both of the applications are incorporated by reference herein in 
their entirety. 

FIELD OF INVENTION 

[0002] The present invention relates to a method for charging for a service in a 
communication network. 

BACKGROUND OF INVENTION 

[0003] In a packet-oriented communication network with service users (SIP clients, 
for example), service providers (application servers, for example), and an application 
broker acting as middleman (SIP proxy, for example), which is not integrated in this link 
for the duration of the service link between a client and an application server (that is, 
which is not a stateful SIP proxy), it is impossible for the proxy to provide a reliable 
charging function for registered customers (users and service providers). For reasons of 
efficiency (hardware and operating costs), it is advantageous for large network 
configurations having a plurality of proxies if a charging unit can work together with a 
plurality of proxies in the network at the same time. 

[0004] - Proxy remains in the communication link for the duration of the service link 
(stateful proxy), or 

[0005] - Billing operates separately between the application server and the client 
without involving the proxy, that is, the operator of the proxy is exclusively an access 
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provider. An overall bill from one source including charges for the services used can then 
only be achieved, if at all, at great expense at the post-processing stage, with separate 
billing functions for the operator of the proxy and for the application server provider. 

[0006] This requires a) assurance that the user of a service is at the same time also a 
customer of the proxy and service operator, and b) transmission of data to the central 
billing unit. 

SUMMARY OF INVENTION 

[0007] The invention describes a method with which it is possible in such a scenario 
comprising a client, proxy (application broker, application brokering unit), charging unit 
(billing server) and application server, for reliable charging to be achieved for all the 
parties involved, the charging additionally representing a value-added service for the 
provider of the basic service (operator of the proxy and of the billing server). This 
provider is thus in a position to offer its end customer a reliable bill from one source with 
packet-oriented services from a very wide range of partner service providers. In such a 
set-up, the basic service provider can assume the role both of a simple broker of a service 
and also that of a middleman with M rebranding M ("rebranding" being understood here such 
that the operator of the proxy offers a service of a partner service provider not under the 
service's original name but under a product name of its own). 

[0008] Ultimately, the aim of this method is 

a) to bill registered end customers (clients) having a credit account in real time for 
charges for services requested and used, or 

b) to provide registered end customers regularly (on a monthly basis, for example) for all 
the services used from various providers. 

[0009] The method ensures that 

a) the customer pays only for what he uses and 

b) the service provider is paid for its services. 
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[0010] This method additionally makes it possible for the customer to have the option, 
even while the service is being used in real time, of having a display showing what 
charges have been run up for the service or, in the case of a prepaid service, how much 
credit is still remaining. 

i * - 

[0011] The basis of the above solution is a reliable charging function which integrates 
all the partner components (client, proxy/application broker, application server) while the 
service is being used. 

Client: authenticates itself with a proxy and requests a service. 

Proxy/application broker : brokers the requested service and initiates charging on the 

billing server. 

Billing server : keeps an account of the use of this service by the client. 

Application server : offers a service and informs the proxy with tickets of the setting up of 

and progress in the service link between itself and the client. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0012] The invention is further explained by a drawing comprising three figures. 

Figure 1 - A schematic of an exemplary embodiment of communication network 

according to the present invention. 
Figure 2 - A schematic of a comparison of three exemplary embodiments; 
Figure 3 - A schematic of an exemplary embodiment of a communication network 

having a plurality of proxies. 

DETAILED DESCRIPTION OF INVENTION 

[0013] Figure 1 shows the links between the partners and an outline of the procedures 
from the authentication of the client to the requesting and supplying of a service and 
finally to charging. These procedures are described hereafter with the aid of Figure 1 . 

[0014] - After the client has authenticated itself on the Authentication Authorization 
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Accounting server (AAA server) by means of the proxy (l)/(2a), the proxy informs the 
billing server of the service request that is waiting. The billing server administers the 
billing table and also generates for it the references pi for each service request. This 
reference is then sent back to the proxy (2b). The proxy then transmits to the client not 
only information as to the location of the application server (destination) and the billing 
reference (pi), but also the address of the billing server (3). As the service continues, the 
client, server and billing server communicate and the proxy is not involved. 

[0015] - With the information that it has received from the proxy, the client requests 
the desired service from the application server (4). The latter confirms the service request 
to the client (5). Thus the service link is established between the client and the application 
server. 

[0016] - After the service link has been set up between the client and the application 
server, and as long as the service is being used, the application server produces tickets at 
regular intervals (1 per minute, for example), which are then sent to the billing server (6). 
These tickets contain the reference pi, which allows the billing server to access the 
billing table efficiently, and the reference si, which the server itself has set up and with 
which it can optionally access its data efficiently later on when it receives feedback from 
the billing server and can terminate an existing service relationship. 

[0017] - After receiving a ticket (6), the billing server determines the identity of the 
client on the basis of the reference pi contained in the ticket (IP address CI) and requests 
from the client a confirmation of these billing data for each ticket received (7). If the 
confirmation has not been received after a certain time has elapsed (e.g. 1 second), the 
request (7) is repeated once or twice. 

[0018] - After receiving the request for confirmation, the client verifies the ticket and 
optionally sends a confirmation to the billing server (8). 

[0019] - After receiving a confirmation from the client, the billing server stores the 
ticket so that a bill can be drawn up at a later date (9) and informs the application server 
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that the client has confirmed the ticket. In the case of a prepaid customer, the billing 
server updates the amount with which the customer is in credit. 

Special cases in the design variant of the invention described : 
[0020] - Prepaid customer: 

If the amount in credit falls below a certain threshold, the billing server informs the client 
that the credit is almost used up. This can be achieved for example by the immediate 
request for confirmation for a ticket (7). 

If the credit has been used up, the billing server will delete the entry in the billing table 
and no longer accept further tickets from the application server for this customer and send 
a negative acknowledgement for these tickets to the application server, whereupon the 
application server will optionally terminate the service link to the client. 

[0021] - If a request for a ticket confirmation from the client (7) has been negatively 
acknowledged: 

The billing server informs the application server that a ticket has been negatively 
acknowledged, giving the reference s 1 back to the application server. Using the reference 
si, the server is then in a position to terminate the service link with the client. 

[0022] - If a ticket confirmation from the client has not been received despite repeated 
requests: 

The billing server informs the application server that it was unable to obtain a receipt for 
a ticket from the client, giving the reference si back to the application server. Using the 
reference si, the server is then in a position to terminate the service link with the client. 

[0023] - If the timer tl for the billing table entry runs out. 

In order to ensure the validity of a billing table entry, the billing server monitors the 
receipt of tickets from the application server. As soon as a ticket (6) comes in, the timer 
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that has been set is reset. When the timer runs out, the entry in the table is deleted. Any 
subsequent tickets that then come in from the server are negatively acknowledged. 
A section of the message procedure (1) - (3), which is shown in Figure 1 and has already 
been described, is shown in Figure 2 for various design variants of the invention. 

[0024] Design variant 1 : The variant described in Figure 1 . 

[0025] Design variant 2 : Variant 2 differs from variant 1 in that the proxy, after the 
billing server has been informed of a request for a connection, no longer expects a billing 
reference (pi) from the proxy, but sends the reply to the client's service request back to 
the client without the pi (3a). Instead the client then expects the billing reference from 
the billing server and only turns to the application server with the service request (4) 
when it has received the billing reference in a separate message (3 b). 

■ 

[0026] Correlation of the information in messages 3a) and 3b) with the original 
service request (1) is achieved via an existing unambiguous reference (call ID, tag) which 
is generated by the client for each service request and is contained in messages 2b), 3a) 
and 3b). 

[0027] Design variant 3 : Variant 3 differs from variant 2 in that in this case, the proxy 
itself does not send the client a reply to the original service request (1). After the billing 
server has been supplied by the proxy with all the relevant data (2b), the billing server 
generates a billing reference pi and sends it to the client in response to the service request 
(1 ), together with the data that it has received from the proxy. 

[0028] Figure 3 shows how the billing server is integrated into the communication 
network as the partner of a plurality of proxies. It gives an outline of the arrangement of 
clients, application servers, proxies and a central billing server. 

[0029] By having the billing servers optionally equipped with internal redundancy and 
by additionally being able to use a plurality of billing servers at the same time, this design 
variant will be highly accessible and at the same time highly scalable (m billing servers 
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for n proxies and z application servers, m < n). 
Observations 

[0030] - It should be noted that this method does not require the server and/or client to 
log off the billing server when the service link has been terminated. This means that even 
the sending of a billing ticket to the client always takes place in advance for the current 
billing interval. This ensures that the client does not use chargeable services without 
paying for them, since it simply disconnects the service before a billing interval has 
expired in order to avoid being charged for the interval that has just elapsed. 

[0031] - The time-out tl in the billing table must always be longer than the length of 
the charging interval agreed between the client and the application server. It has to be 
long enough to prevent a ticket message to the billing server that has gone astray (and is 
therefore repeated by the application server) from leading the billing server to declare the 
billing table entry invalid. At the same time, however, tl must not be too long in order to 
avoid, for example, denial of service attacks by malicious clients leading to a shortfall in 
billing table resources and ultimately to non-availability of these services. A sensible 
value for tl is 2-3 times the length of the billing interval. Since the length of the billing 
intervals for the individual service links (see Fig. 1) can vary, the length of the time-out 
tl is designed to be variable. As soon as the billing server receives a ticket from the 
application server, it uses the length of the billing interval quoted therein and determines 
therefrom the length of tl in order to monitor the receipt of the next ticket from the 
application server for this service link. Until the first ticket has been received from the 
application server, a fixed initial value that is standard for the billing table is used for this 
timer (5 seconds, for example). 

[0032] - Possible confidence-building measures between the client and application 
server: the conditions for the service link (length and cost of the first interval, length and 
costs of the subsequent intervals) are agreed between the client and the server. By 
selecting a short first interval and optionally special conditions for this, it can be ensured 
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even in a case of the service not being provided (e.g. server failure, overload, SW error, 
incompatibility of client and server software), despite the fact that a service link has been 
established, that the service user is not disadvantaged or is disadvantaged only to a slight 
extent. 

[0033] - If the billing server fails, the application server can optionally disconnect the 
service link to the client due to the fact that no receipt is generated for the ticket. 

[0034] - If the client fails, the customer's charge account will not continue to be billed 
in error by the billing server since the client is no longer in a position to quit further ticket 
confirmation requests from the billing server (see special cases). 

[0035] - Functionality for the client extendable to include for instance: 

i. Cumulation of the billing messages transmitted by the billing server and display of 
these charges on the terminal to allow monitoring of the charges in real time. 

ii. Possibility for end users to refuse manually in the form of option tickets, when, for 
example, a certain self-determined charge limit has been reached. 

[0036] The invention can be summarized as follows. The method described allows the 
operator of a stateless proxy or application broker to provide registered application 
service providers and registered customers, in a simple manner by means of a billing 
server, with a reliable charging function that is trustworthy and accurate in definable 
intervals. The way that this is achieved is that, during the provision of the service, the 
client and server are continuously communicating in the background at regular intervals 
via an independent third party (billing server) regarding the charges applicable for the 
service, and the charging function is also facilitated by the independent third party, the 
charging function on the billing server being facilitated in particular for a plurality of 
proxies at the same time. 

Examples of applications 
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- information services 

- video services 

- enhanced telephone services, such as conferences via conference servers 

- checking mailboxes 

- anonymous billing for gateways which are accessed via the open internet. 
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